Now we deterministically exit from the poller loop. 👌

Codecov Report

❌ Patch coverage is 93.47826% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 85.92%. Comparing base (c5371bd) to head (b8e20d2).

@@            Coverage Diff             @@
##           master    #8017      +/-   ##
==========================================
- Coverage   88.04%   85.92%   -2.12%     
==========================================
  Files        1907     1372     -535     
  Lines       73282    56786   -16496     
  Branches     1302      650     -652     
==========================================
- Hits        64519    48795   -15724     
+ Misses       8374     7762     -612     
+ Partials      389      229     -160     

After a very useful conversation with my new best friend Gemini, here's the best understanding I have of how to handle asyncio tasks. I will "publish" it here because I think it is very insightful:

The Critical Difference: Where the Program Hangs

So what is the "guarantee" that TaskGroup provides?

The guarantee is not that the task will be killed instantly. The guarantee is structural: The TaskGroup guarantees that your program will not proceed past the async with block, leaving an orphaned task behind.

Let's compare the two scenarios:

Scenario 1: Manual Cancellation (The "No Guarantee" case)

   1 async def my_parent_task():
   2     task = asyncio.create_task(un_cancellable_task())
   3     task.cancel()
   4     # My parent task MOVES ON, thinking it cancelled the child.
   5     # The child is now an ORPHAN, running forever in the background,
   6     # potentially holding resources and causing silent bugs.
   7     print("Parent task finished, but the problem is hidden.")

Here, the guarantee fails because your parent task has a completely incorrect view of the system's state.

Scenario 2: Using TaskGroup

    1 async def my_parent_task():
    2     try:
    3         async with asyncio.TaskGroup() as tg:
    4             tg.create_task(un_cancellable_task())
    5             # Let's say another task in the group finishes,
    6             # triggering the cleanup and cancellation of un_cancellable_task().
    7     except Exception:
    8         pass
    9 
   10     # THIS LINE IS NEVER REACHED.
   11     # The `async with` block itself hangs forever, waiting for the
   12     # un_cancellable_task to finish.
   13     print("Parent task finished.")

Here, the TaskGroup surfaces the problem. It doesn't hide it. The program hangs at the exact point where the misbehaving task is preventing cleanup. You now have a clear
place to debug. The guarantee is that you cannot have "zombie" or "orphan" tasks that you don't know about. The TaskGroup forces you to confront them.

The Real Solution: Combining TaskGroup with Timeouts

So, how do you get the best of both worlds? A guarantee of no orphans, and a guarantee that your parent task won't hang forever?

You wrap the entire TaskGroup in a timeout. This is the ultimate pattern for robust concurrent code.

    1 import asyncio
    2 
    3 async def un_cancellable_task():
    4     print("Un-cancellable task started and will ignore cancellation.")
    5     # This task has no await, so it can't be cancelled.
    6     for i in range(10_000_000_000):
    7         pass
    8     print("This will never be printed.")
    9 
   10 async def main():
   11     print("Starting main task.")
   12     try:
   13         # Python 3.11+ has the cleaner `asyncio.timeout()`
   14         async with asyncio.timeout(2):
   15             async with asyncio.TaskGroup() as tg:
   16                 tg.create_task(un_cancellable_task())
   17                 # The TaskGroup will try to cancel the task when the
   18                 # outer timeout is triggered.
   19 
   20     except asyncio.TimeoutError:
   21         print("The entire operation timed out after 2 seconds.")
   22         print("The un-cancellable task is now orphaned, but we KNOW it.")
   23         print("Our main program flow is safe and can continue.")
   24 
   25     print("Main task has finished.")

This is the pinnacle of asyncio safety:

1. The TaskGroup ensures all tasks within the operation are managed as a single unit.
2. The asyncio.timeout() ensures that your application's control flow will always proceed, even if one of the tasks inside the group misbehaves and refuses to cancel.

Thanks for further investigation, it's similar to the solution adopted for Celery's tasks monitoring. 👌

I would still like to have 1 code for this and not 2 different ones. Also, you are aware that @cancel_on_disconnect will also cancel any Starlette BackgroundTask in the request right?

OK, I will refactor to use only one version of the code in both of these. But I will keep both ways: a decorator and a middleware.

Yes, I am aware that @cancel_on_disconnect will cancel a Starlette Background task. We have one endpoint in the api-server where we use those (the logstreaming) and we don't use this decorator there. So that should be fine.

@bisgaard-itis I had some interesting experiences with these cancellations in my PR #8014 where I added uvloop also in the testing (up to now we were using uvloop in production and asyncio std loop for testing). We can talk on Monday about it

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud